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Abstract 


This document defines an additional mode of the link-layer assisted 
RObust Header Compression (ROHC) profile, also known as the zero-byte 
profile, beyond the two defined in RFC 3242. Zero-byte header 
compression exists in order to prevent the single-octet ROHC header 
from pushing a packet voice stream into the next higher fixed packet 
size for the radio. It is usable in certain widely deployed older 
air interfaces. This document adds the zero-byte operation for ROHC 
Bidirectional Reliable mode (R-mode) to the ones specified for 
Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes 
of header compression in RFC 3242. 


1. Introduction 


[RFC3242] defines a zero-byte solution for compression of IP/UDP/RTP 
packets only for Unidirectional (U-) and Bidirectional Optimistic 
(O-) modes [RFC3095]. The present specification extends the profile 
defined in [RFC3242] to provide zero-byte support for Bidirectional 
Reliable (R-) mode. This specification and [RFC3242] allow a 
header-free packet format to be used in all modes to replace the 
majority of the 1l-octet headers of ROHC RIP packets sent during 
normal operation. Specifically, the compressor operating in R-mode 
is allowed to deliver a No-Header Packet (NHP) when [RFC3242] would 
have required it to deliver a ROHC Reliable Packet Type Zero (R-0) 
packet [RFC3095]. 
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For simplification, this profile is defined in the form of the 
additions and exceptions to [RFC3242] that are required to extend the 
RFC 3242 profile with zero-byte support for R-mode. All terminology 
used in this document is the same as in [RFC3242]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


2. Extensions to the assisting layer (AL) interface 


This section describes additions (some are optional) to the assisting 
layer interface as defined in [RFC3242, section 4.2]. 


2.1. Additional parameters to the compressor to AL interface 


- Mode, indicating the mode in which the compressor is operating. 
The AL has slightly different logic depending on the mode value. 


- SN_ACKed, indicating the latest RTP SN that has been acknowledged. 
It is used only when Mode value = R-mode. 


Note that these two parameters MUST always be attached to every 
packet delivered to the AL. 


2.2. Additional interface, assisting layer to compressor 


To improve the compression efficiency of this profile in some 
specific cases, e.g., when the AL operates in such a way that it 
often becomes unsafe to send NHPs, it is RECOMMENDED to implement 
this additional interface. Here, the word "unsafe" means that the 
compressor allows the AL to send NHP but the AL cannot guarantee that 
the RTP SN of the NHP will be correctly decompressed at the receiving 
side. The interface is used to carry update_request as described in 
section 3. Note that this interface is not required in the sense 
that the impossibility of implementing such an interface should not 
be an obstacle to implement this profile over a specific link. 


3. R-mode operation 


For the R-mode, this profile extends ROHC RTP by performing a mapping 
of the R-0 packet to the NHP packet. Note that R-0 is the only type 
of packets in R-mode that can be replaced with NHP. 


On the receiving side, the RTP SN of an NHP is determined by the 
decompressor as = SN_Ref_D + Offset_D, where SN_Ref_D is the RTP SN 
of the last update packet received by the decompressor, and Offset_D 
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the sequence number offset between the NHP and the last update 
packet. How to derive Offset_D depends on the implementation of this 
profile over a specific link technology and must be specified in the 
implementation document(s). For example, it can be calculated by 
counting the total number of non-context-updating packets (including 
NHPs) and packet loss indications received since the last successful 
context update. Alternatively, it can be derived using the link 
timing in the case where the linear mapping between RTP SN and link 
timing is maintained. 


On the transmitting side, the AL follows the same rule defined in 
section 4.1.1 of [RFC3242] to determine whether it can send NHP or 
not, with one modification. That is, when the AL determines that it 
has become unsafe (see section 2.2) to send NHPs, the AL records the 
corresponding RTP SN as SN_break. Then it waits until the rule is 
satisfied again and SN_ACKed > SN_break before it resumes sending 
NHPs. The latter condition is essentially the counterpart of 
optimistic approach agreement [RFC3242, section 4.3] of U/O-mode 
which states that when the AL in U/O-mode determines it is unsafe to 
send NHP, it must send headers in the subsequent X packets, where X 
is some agreed number. There are two reasons for the difference: a) 
R-mode relies on acknowledgements to synchronize contexts, instead of 
optimistic approach principle as in U/O-mode; and b) R-O packets do 
not update decompressor context while UO-0 packets do. To meet the 
condition SN_ACKed > SN_break, the AL can either wait passively for 
the compressor to send a context update packet (e.g., R-O-CRC 
triggered by 6-bit SN wrap-around), or send an update reguest via the 
interface from AL to the compressor (section 2.2) to request the 
compressor to send a context updating packet. The update_request 
carries the last SN_break. Upon receiving an update_request, the 
compressor SHOULD use a context updating packet (e.g. R-O-CRC) when 
sending the next packet. Context updating packets are handled as in 
[RFC3095]. 


Note: the passive waiting as described above might take a long time 
in the worst case, during which NHPs cannot be sent. Therefore, 
sending update_request via the optional AL to compressor interface is 
RECOMMENDED to improve the worst case performance. 


Note: the update_request may be lost if the AL and compressor are at 
different locations and the channel between them is unreliable, but 
such a loss only delays the AL from resuming sending NHP. Therefore, 
how frequent the AL sends update_request is an implementation issue. 
For example, the AL may send one update_request for each packet it 
receives from the compressor until the conditions to send NHP are 
met. 
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Note: as no CRC field is present in R-0 packets, only the function 
related to RTP SN and packet type identifier needs to be replaced. 

In addition, NHP packets and packet loss indications in R-mode do not 
update either the compressor or the decompressor context (as opposed 
to U/O-mode). Consequently, the secure reference principle [RFC3095, 
section 5.5] is not affected in any way and there is no loss of 
robustness in this profile compared to ROHC RTP. 


4. Differences between R-mode and U/O-mode 


This section clarifies some differences between R-mode and U/O-mode 
in this profile. 


a) 
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CRC replacement 
Unlike U/O-mode, CRC replacement [RFC3242, section 3.3] is not an 
issue for R-mode since R-0 packets do not carry CRC field. 


Periodic context verification 

For U/O-mode, periodic context verification [RFC3242, section 4.6] 
is RECOMMENDED to provide additional protection against damage 
propagation after CRC is replaced. For R-mode, since there is no 
CRC replacement (see above), no change to ROHC RTP is needed in 
this regard. In particular, R-mode has this feature naturally 
built-in, since the sending of R-O-CRC when 6-bit SN wraps around 
implicitly provides periodic context verification for R-mode. 


CV-REQUEST option 

For the same reasons as above, the decompressor operating in R- 
mode SHOULD NOT send CV-REQUEST [RFC3242, section 4.5] to 
compressor. This is to avoid unnecessary overhead on the feedback 
channel. 


Context Check Packet (CCP) 

When CCP [RFC3242, section 4.1.3] is used, compressor operating in 
R-mode SHOULD set C-bit to 0 (zero) and not generate 7-bit CRC if 
computation cost at compressor and decompressor causes concern. 
The use of the CRC field in CCP to perform decompressor context 
verification is not critical in R-mode (see last note of section 3 
and item b) above). 


Handling of Acknowledgements (ACKs) 

Special care in the realization of ACKs should be taken for R-mode 
implementations. It is RECOMMENDED to avoid the use of 
interspersed feedback packets [RFC3095, section 5.2.1] to carry 
ACK information. The reason is that interspersed feedback packets 
will interrupt the RTP SN sequencing and thus temporarily disable 
the sending of NHPs. 
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5. IANA Considerations 


A ROHC profile identifier has been reserved by the IANA for the 
profile defined in this document (0x0105), where 0x0005 is the 
profile identifier assigned for LLA [RFC3242]. 


6. Security Considerations 


The security considerations of ROHC RTP [RFC3095, section 7] apply 
also to this document with one addition: in the case of a denial-of- 
service attack scenario where an intruder injects bogus CCP packets 
onto the link using random CRC values, the CRC check will fail for 
incorrect reasons at the decompressor side. This would obviously 
greatly reduce the advantages of ROHC and any extra efficiency 
provided by this profile due to unnecessary context invalidation, 
feedback messages and refresh packets. However, the same remarks 
related to the presence of such an intruder apply. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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